home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-hitchcock-eid-00.txt < prev    next >
Text File  |  1993-06-07  |  12KB  |  293 lines
  1.  
  2.  
  3.  
  4.     Big Internet                                                D. Hitchcock
  5.     INTERNET-DRAFT                                              U.S. DOE       
  6.                                                                     May 1993
  7.  
  8.  
  9.                   Endpoint Identifiers: What do they do and why
  10.                               are they a good thing?
  11.  
  12.  
  13.     Status of this Memo
  14.  
  15.           This document is an Internet Draft. Internet Drafts are working
  16.     documents of the Internet Engineering Task Force (IETF), its Areas, and
  17.     its Working Groups. Note that other groups may also distribute working
  18.     documents as Internet Drafts).
  19.  
  20.           Internet Drafts are draft documents valid for a maximum of six
  21.     months. Internet Drafts may be Updated, replaced, or obsoleted by other
  22.     documents at any time. It is not appropriate to use Internet Drafts as
  23.     reference material or to cite them other than as a "working draft" or
  24.     "work in progress."
  25.  
  26.           Please check the I-D abstract listing contained in each Internet
  27.     Draft directory to learn the current status of this or any other Internet
  28.     Draft.
  29.  
  30.  
  31.     Abstract
  32.  
  33.           There has been an ongoing debate on the Big Internet list over the
  34.     past year over whether abstracting the concept of Endpoint Identifier
  35.     (EID) from the concept of address which has significance in the topology
  36.     of the network. This draft attempts to summarize the arguments pro and con
  37.     as well as some discussion of whether the EID should be in the network
  38.     layer or elsewhere. This draft also contains a specific proposal for EID
  39.     format with a discussion of the pros and cons of this choice.
  40.  
  41.  
  42.     1. Some Background
  43.  
  44.           The assignment of addresses in the internet follows a tree of
  45.     Address Assignment Authorities. At the root of the tree is the top-level
  46.     (or 0-level) AAA. This AAA assigns blocks of numbers to the next level
  47.     down (1-level) AAA, which assigns blocks of numbers from the block it owns
  48.     to 2-level AAAs and so on. If a traditional left-to-right bit- wise
  49.     significant address is used, these blocks of numbers are low- order-bits-
  50.  
  51.     Big-Internet, Expires November 1, 1993                            [Page 1] 
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.     INTERNET-DRAFT         EID's: Pro and Con                      April 1993
  60.  
  61.     maskable binary numbers. 
  62.  
  63.           Current internet technology is approaching the end of its useful
  64.     life due to the expansion in the number of attached networks and hosts.
  65.     These expansions have resulted in two problems, depletion of the
  66.     assignable address space and explosion in the amount of information
  67.     exchanged especially between the top level backbone service providers.
  68.     There are a number of proposals currently under consideration to support
  69.     the future growth of the internet: TUBA, SIP, IPAE, PIP, Nimrod,... as
  70.     well as a near term proposal CIDR to help address these problems as well
  71.     as some others. It is likely that some number of these technologies will
  72.     need to coexist and interoperate for some period of years.
  73.  
  74.           All of these proposals must address the issue of how to assign these
  75.     numbers so that 1) routing scales well, 2) good paths are found, 3)
  76.     constraints on the physical topology are minimized, and 4) reconfiguration
  77.     of systems is minimized. If one creates a graph where the vertical axis is
  78.     scaling (bottom is perfect scaling in top is bad scaling) and the
  79.     horizontal axis is path quality (left is perfect paths and right is bad
  80.     paths), then the optimal operating point on the graph is the lower left
  81.     corner. In general the "physics" of networking forces operating points on
  82.     this graph to be at the upper left or lower right. Depending on the type
  83.     of address assignment scheme used, however, it is possible to move
  84.     somewhat towards the lower left (good solutions) or the upper right (bad
  85.     solutions). Moving to the lower left, however, may increase topology
  86.     constraints or reconfiguration requirements.
  87.  
  88.           Central to the evaluation of any address assignment scheme are
  89.     answers to the questions 1) what constitutes good scaling, 2) what
  90.     constitutes a good path, 3) what constitutes unacceptable or costly
  91.     topology constraints, and 4) what constitutes unacceptable or costly
  92.     reconfiguration. I suspect that the community has or will come to
  93.     reasonable agreement on what the characteristics of each address
  94.     assignment scheme are. Except for possibly the first question, I also
  95.     suspect that the community will not agree on the answers to the questions,
  96.     partly because the cost of each aspect is borne by different parties, and
  97.     partly because we lack experience.
  98.  
  99.           In the current IP technology the IP number is both the identifier of
  100.     a computer system and the carrier of the topological information the
  101.     network uses to determine how to route information.
  102.  
  103.     2.    What is an Endpoint Identifier (EID)?
  104.  
  105.           For the purposes of this draft an EID is a fixed length string of
  106.     defined structure which uniquely identifies a "network endpoint." EID's
  107.     have the following properties:
  108.  
  109.           A single EID may have associated with it multiple network attachment
  110.  
  111.     Big-Internet, Expires November 1, 1993                            [Page 2] 
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.     INTERNET-DRAFT         EID's: Pro and Con                      April 1993
  120.  
  121.           points with multiple addresses.
  122.  
  123.           A single address can be associated with only one EID at any one time
  124.           although the binding of addresses to EID's may change over time.
  125.  
  126.           EID's are assigned so that they are unique network wide.
  127.  
  128.           EID's differ from DNS names in that they are fixed length as well as
  129.           in some other details... MX records, Cnames,...
  130.  
  131.           EID's are stable over time and are not created or destroyed too
  132.           quickly.
  133.  
  134.           EID's are network layer objects in the sense that all transport and
  135.           higher layer services on a given endpoint use the same EID.
  136.  
  137.     In order to make these definitions more specific we must define exactly
  138.     what we mean by a "network endpoint."  This is to some extent a choice of
  139.     the most appropriate granularity for stable descriptions of network
  140.     entities.  The critical elements of the definition of an endpoint are the
  141.     concept of fate-sharing developed by Chiappa and the concept of stability. 
  142.     In most cases a network endpoint is a single computer system.  However,
  143.     there are cases where a single system might have more than one EID
  144.     especially for systems in a multilevel secure environment.
  145.  
  146.     3.    What problems do EID's address?
  147.  
  148.     Virtually all the proposals for IPv7 as well as the near term CIDR
  149.     proposal will require significant portions of the internet community to
  150.     modify their internet addresses, either the assignment, the format, or
  151.     both. Furthermore, in the foreseeable future the topological information
  152.     required by the network to reach a given destination will become more
  153.     changeable  rather than less changeable because:
  154.  
  155.           commercial providers will be very motivated to change the topology
  156.           to achieve more balance utilization of their investment in
  157.           connections.
  158.  
  159.           the sources and destinations of network traffic will themselves
  160.           become mobile or changeable.
  161.  
  162.     The current IP addressing and routing technology does not provide easy
  163.     answers to these problems. In fact the way IP host software is currently
  164.     implemented implies that it is very difficult to  accommodate these
  165.     issues.  The administrative problems of renumbering even a medium sized
  166.     site using today's tools is formidable and requires at least rebooting
  167.     every machine.
  168.  
  169.     One reason for these problems is that IPv4 uses the IP address both to
  170.  
  171.     Big-Internet, Expires November 1, 1993                            [Page 3] 
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.     INTERNET-DRAFT         EID's: Pro and Con                      April 1993
  180.  
  181.     route packets and to identify sources and destinations of packets.
  182.  
  183.     4.    The Case for and Against EID's
  184.  
  185.     The arguments for EIDs include:
  186.  
  187.      1.   System identification and location are qualitatively different
  188.           functions and so should be separated architecturally.
  189.  
  190.      2.   EID's may facilitate mobile hosts.
  191.  
  192.      3.   EIDs may allow global changes in network topology without disrupting
  193.           ongoing processes.
  194.  
  195.      4.   EID's may facilitate management of local sites in an environment
  196.           where "addresses" need to be changed fairly frequently.
  197.  
  198.     The argument against EID's include:
  199.  
  200.      1.   Its an extra number space to manage.
  201.  
  202.      2.   The essential features of the EID are provided by the DNS name
  203.           (since there is no need for EID's in every packet.)
  204.  
  205.      3.   EID's may not be the only  way to provide mobility and portability
  206.           of processes.
  207.  
  208.     Complicating this discussion is the fact that all of these different
  209.     advantages and disadvantages have different levels of importance for
  210.     various people.  In my own view advantages 3 and 4 are very important but
  211.     other people have different priorities.  
  212.  
  213.     Also, to be clear about my biases, having a single network layer service
  214.     EID that multiple higher layer processes could use seems much simpler and
  215.     easier to manage than a multitude of higher level processes to perform the
  216.     same functions on  a process by process basis.
  217.  
  218.     5.    EIDs and DNS Names
  219.  
  220.     One issue which needs to be clarified is the realtionship between DNS
  221.     names and EIDs.  
  222.  
  223.           EIDs are fixed format identifiers which are suitable for inclusion
  224.           in every packet; although this may not be required.
  225.  
  226.           EIDs do not support the logical constructs equivalent to CNAMEs and
  227.           MX records in the DNS.
  228.  
  229.           One of the major applications which one would like to be robust when
  230.  
  231.     Big-Internet, Expires November 1, 1993                            [Page 4] 
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.     INTERNET-DRAFT         EID's: Pro and Con                      April 1993
  240.  
  241.           addressing topology changes is the DNS.  While it is possible to
  242.           imagine complex bootstrap procedures for the DNS to accomplish this
  243.           if DNS names were used as EID's transforming the DNS search tree to
  244.           refer to EIDs rather than addresses is likely to be a much simpler
  245.           way of accomplishing this.
  246.  
  247.     5.    Proposed Experiment
  248.  
  249.     However, without real experience with EID's it is impossible to accurately
  250.     evaluate any of this. Therefore, I would like to propose the following EID
  251.     experiment.
  252.  
  253.           Choose an EID format which is the same as the current IPv4 and build
  254.           an implementation which uses two copies of IPv4 one for routing and
  255.           one for EID (one could even use the current IP address as EID and
  256.           add a RD - routing directive - object which looks like IPv4 to
  257.           minimize the impact on current software implementations).  
  258.  
  259.           Assume EID assignment follows current DNS delegation procedure.
  260.  
  261.           Modify DNS so it can supply EID as well as "address"
  262.  
  263.           For all those old applications which use the DNS name and "address"
  264.           replace "address" with EID
  265.  
  266.  
  267.           Define EARP (EID ARP) which is same as plain old ARP  but uses EID
  268.           instead of "address."
  269.  
  270.     Some of the issues which would need to be addressed are how to propagate
  271.     changes in EID-"address" binding in real time and maintain coherent view
  272.     of the network. I propose that SNMP be used to build the right fragments
  273.     to manage this.
  274.  
  275.     Note that once a router passes the EID to a layer 2 subnet the delivery of
  276.     packets works just as it does in IP because of EARP.  
  277.  
  278.     This testbed is, it seems to me, the minimal thing that one can do to
  279.     evaluate how useful EIDs would be.  In addition, it has the side benefit
  280.     that if it were successful it could lead to an EID structure which would
  281.     be directly useful in CIDR.
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.     Big-Internet, Expires November 1, 1993                            [Page 5] 
  292.  
  293.